Congestion handling in a packet switched network domain

ABSTRACT

A system and a method are described herein which provide for congestion handling in a packet switched network domain. In case of congestion overload is measured by a core node, the data packets in proportion to the overload are marked and the signaled overload is stored. At least one egress node receives marked and not marked packets, decodes and counts the overload from the marked packets in a counting interval. Congestion report messages are sent to ingress nodes where flows are terminated.

CLAIM OF PRIORITY

This application is a continuation application of U.S. patentapplication Ser. No. 11/718,854, filed May 6, 2007, now pending, whichis a 371 of PCT/SE04/01657 filed on Nov. 12, 2004. The contents of thesedocuments are hereby incorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Technical Field of the Invention

The invention relates in general to congestion handling of a packetswitched network domain. In particular, and not by way of limitation,the present invention is directed to congestion handling in an InternetProtocol (IB) network domain.

2. Description of Related Art

Recently, IP-based transport solutions are considered for 3rd generation(3G) networks because of the flexibility and wide deployment of IPtechnologies. These networks have different characteristics whencompared to traditional IP networks requiring fast dynamic resourcereservation, simplicity, low costs, severe congestion handling, and goodscalability properties. Besides, 3G networks have strict Quality ofService (QoS) requirements. Traffic congestion control is thus animportant consideration, in communications networks. One method ofnetwork management that may be suitable for use in future networks, isthe so called policy-enabled networking. An example of thepolicy-enabled networking is QoS provisioning using the so-called‘DiffServ’ architecture. ‘DiffServ’ refers to the IP DifferentiatedService architecture, where QoS provisioning is obtained by marking dataunits. Different marked packets will receive a different priority inqueuing and/or scheduling of nodes.

The Internet Engineering Task Force (IETF) has specified resourcereservation signaling protocols, such as RSVP [R. Braden et al.:“Resource Reservation Protocol (RSVP)—Version 1 FunctionalSpecification”, RFC 2205, September 1997], and different QoS models,such as Integrated Services [R. Braden, et al.: “Integrated Services inthe Internet Architecture; an Overview”, RFC 1633, 1994], [J.Wroclawski: “The Use of RSVP with IETF Integrated Services”, RFC 2210,September 1997] or Differentiated Services [S. Blake, et al.: “AnArchitecture for Differentiated Services”, RFC 2475, 1998], forproviding QoS in an IF network. In the Next Steps In Signaling (NSIS)Working Group (WG) of IETF a new QoS signaling protocol, aiming to meetthe requirements of 3G networks and different real time applications, isunder development.

The future NSIS protocol will support different QoS models and operationnodes including Resource Management in Differentiated Services (RMD) [L.Westberg et. al.: “Resource Management in Diffserv (RMD): AFunctionality and Performance Behavior Overview”, Protocols for HighSpeed Networks 7th IFTP/IEEE International Workshop, PfHSN 2002, Berlin,Germany, Apr. 22-24, 2002. Proceedings Series: Lecture Notes in ComputerScience, Vol. 2334 Carle, Georg; Zitterbart, Martina (Eds.) 2002, X, 280pp., Softcover ISBN: 3-540-43658-8], patent publication WO2002076035A1],RMD is a scalable and dynamic resource reservation method based onDiffServ and it is able to work together with standard IP routingprotocols. This allows fast re-routing in case of link or node failure,which is one of the major advantages of IP networks comparing to othertransport technologies such as AAL2/ATM [3GPP TSG RAN: “IP Transport inUTRAN Work Task Technical Report” 3GPP TR 25.933, 2003].

In RMD scalability is achieved by separation of the complex per domainreservation mechanism from the simple reservation mechanism needed for anode. Complex functions are performed at edge nodes and core nodes areinvolved only in simple operations. In such a system edge nodes performcomplex operation and store per-flow information while core nodes in thedomain perform simple operation and do not store per-flow states. Insuch a resource management system, two basic operation modes can bedistinguished: normal operation and fault handling. Normal operationincludes making a new reservation, refresh reservations, and tear downreservations. Fault handling is needed if quailty-of-service sensitiveflows experience service degradation due to congestion. Basic featuresof normal operation and fault handling operation modes are described inA. Császár et al.: “Severe Congestion handling with Resource Managementin DiffServ on Demand”, In proc. of the Second International IFIP-TC6Networking Conference, Networking2002, pp. 443-454, May 2002, Pisa,Italy.

Severe congestion is considered as an undesirable state, which may occuras a result of a route change. Typically, routing algorithms are able toadapt and change their routing decisions to reflect changes in thetopology (e.g., link failures) and traffic volume. In such situationsthe re-routed traffic will have to follow a new route. Nodes located onthis new path may become overloaded, since they suddenly might need tosupport more traffic than their capacity. The resource managementprotocol in reaction to severe congestion has to terminate some flows onthe congested path in order to ensure proper QoS for the remainingflows.

Congestion occurrence in the communication path has to be notified tothe edge nodes of the affected flows, since core nodes do not have perflow identification. The congestion handling control loop consists ofthe following steps: (1) A core node that detects congestion markspassing packets, which are forwarded to an egress node. This way, (2)the egress node learns the overload ratio and decides accordingly whichflows should be dropped. For these flows the egress node generates and(3) sends a report, to an ingress node to reduce the traffic volumeinjected by the ingress node. This signal could be a RSVP tear downmessage or error message or NSIS response or any other kind of messagedescribing the overflow of traffic volume. Upon reception of thissignalling packet, (4) the ingress nodes terminate the appropriateflows.

The congestion algorithm described above and which is used also in theoriginal RMD concept over-reacts congestion events terminating moreflows than necessary to cease congestion. This effect can be seen as an“undershoot” in the link utilization graph of the affected links.

The reason of the over-reaction is the delayed feedback of the overloadsituation. After detecting the congestion situation, the core nodenotifies the egress nodes by marking data packets that pass through thenode so that the sum size of the marked packets compared to allforwarded bytes is proportional to the overload. When the marked packetsarrive at the egress node, it summarizes the size of marked, andunmarked packets. Eased on these two counters, the egress nodecalculates the overload ratio and decides which flow or flows toterminate. The core nodes do not have per flow information and theycannot have information about the previously marked packets per flow. Incase of congestion they continue marking the packets until the measuredutilization falls below the threshold. Since marking is done in corenodes, the decision is made at the egress node, and termination of flowsare done in ingress node there is a delay between these events. In theingress node the number of terminated flows is determined by previouslymarked packets. Thus, it can happen that, there is no congestion anylonger in the core node but the ingress node still terminates a numberof flows determined in a previous time interval when congestion wasdetected.

We have set ourselves the objective with this invention to improve thesolutions described above by handling the congestion more effectively ina packet switched network domain especially in an IP domain.

SUMMARY OF THE INVENTION

Accordingly, the object of the invention is a system providingcongestion handling in a packet switched network domain, which domaincomprises nodes that are linked to each other and transmitting datapackets in the network domain. In case of congestion overload ismeasured, the data packets are marked to encode and signal the amount ofoverload, and the signalled amount of overload is stored in a core nodeto take into account the previously signalled overload. At least oneegress node is arranged to receive marked and not marked packets, decodethe overload from the marked packets in a counting interval, identifyflows to be terminated and report to ingress node to reduce the trafficvolume.

In another aspect, the present invention is directed to a core nodecomprising a storage means taking into account the previously signaledoverload.

In yet another aspect, the invention refers to an egress node comprisingmeans for adding new flows to the set of identified affected flows,means for identifying affected flows so that their aggregated load isequal to the overload value derived from the marked packets, and meansfor removing flows to be terminated from the set of affected flows.

In addition, the invention refers to a method for congestion handling ina packet switched network domain comprising steps of measuring overloadand marking data packets to encode and signal the amount of overload;receiving marked and not marked packets; decoding the overload from themarked packets in a counting interval; identifying the flows to beterminated; sending congestion report messages to ingress nodes, andterminating the flows in at least one ingress node. The method furthercomprises a step of storing the signaled amount of overload taking intoaccount the previously signaled overload.

Especially, the invention can foe applied in a Differentiated Servicesconform IP domain.

The most important advantage of the invention is that less number offlows is terminated and so more effective link utilization is achieved.

It is also advantageous that congestion handling method, according tothe invention can be applied in other resource management systems,especially in which core nodes are stateless or reduced state nodes andstate-full edge nodes or a state-full higher-layer application areresponsible for handling a congestion situation.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the invention, reference is made tothe following detailed description taken in conjunction with theaccompanying drawings wherein:

FIG. 1 is an embodiment of a domain in an IP network;

FIG. 2 is a flow chart illustrating a possible embodiment for congestionhandling according to the invention;

FIG. 3 illustrates an embodiment of a core node according to theinvention;

FIG. 4 shows the flow chart of the operation of a possible egress nodeaccording to the invention;

FIG. 5 depicts a graph of a network simulation for congestion;

FIG. 6 illustrates an example for method of sliding window.

DETAILED DESCRIPTION OF THE INVENTION

In FIG. 1 an example of a domain 101 in an IP network is illustrated.The domain 101 consists of edge nodes 102, 103 and core nodes 104, 105,106 and links 107, 108, 109, 110, 111 between them. Ingress 102 andegress 103 nodes are edge nodes in the domain 101, handling per flowinformation while core nodes 104, 105, 106 store only aggregatedinformation, typically per traffic class aggregated information. Normaloperation and operation in case of loss of signaling for such a systemare described for instance in A. Császár et al.: “Severe CongestionHandling with Resource Management in DiffServ on Demand”, in proceedingsof the Second International IFIP-TC6 Networking Conference,Networking2002, pp, 443-454, May 2002, Pisa, Italy. Here only a newcongestion handling solution is discussed.

In case of link failure 112, for example, routing algorithms in IPnetworks will adapt by changing the routing decisions taking intoaccount the topology and traffic volume. As a result the re-routedtraffic will follow a new path, which may result in overloaded links,e.g., link 109, as they need to support more traffic than their capacityallows. This causes congestion in the communication path from which theedge nodes 102, 103 have to foe notified, to take appropriatecounter-measures on the flow level.

In FIG. 2 an algorithm for handling congestion is illustrated. The stepsof the algorithm are as follows: When a failure of a link occurs in adomain 201, the traffic of this link is re-routed to new paths 202,loading links on the new paths with unexpected traffic. If the volume ofthis additional traffic causes congestion 203 at a node, then this nodemeasures the overload 204. Before forwarding regular data packets, someof them are marked 205. The amount of overload is encoded and signalledwith packet markings. The overload value encoded in a packet could becalculated, e.g., proportional to the size of the packet or the markingof a single packet may correspond to a unit, of overload. The signalledamount of overload is stored 206. After that the egress node receives207 the marked and not marked packets (dashed line 113 in FIG. 1).

To solve the problem of over-reaction and get a more precise behaviour akind of memory is introduced in the core nodes remembering a fewmeasurement periods back the previously signalled overload. The time torwhich the storage remembers the signalled overload should be in theorder of the round trip time (RTT) of the messages in the domain; e.g.,the minimal, average or maximal possible RTT in the domain.

This way the amount of marked packets can be calculated by taking intoaccount the previously signalled overload. Typically, the requiredoverload value of marked packets at the beginning of a period is equalto the overload measured in the previous period minus the sum of alreadysignalled overload stored in the memory.

After receiving the packets, the egress node decodes the overload valuefrom the marked packets in a counting interval 208, and identifies theflows to be terminated 209 so that the selected flows together producedan amount of data during the counting interval that is equal (or close)to the decoded overload. The difference between the decoded overload andthe load generated by the terminated flows is remembered for the nextperiod in order to achieve a precise behaviour if during a period eithermore or less flows are selected to terminate than indicated from, theoverload. Different, methods can foe applied to select which flowsshould be terminated. For example, short- or long-life flows could beprivileged, small- or high-bandwidth flows could be chosen first and soon. In a preferred embodiment the flows to be terminated are randomlyselected among the flows that pass the congested link.

Anyway, the egress nodes send congestion report messages 210 (dottedline 114 in FIG. 1) back to the ingress nodes, (In FIG. 1, only oneingress node 102 is illustrated). The ingress nodes then terminate theflows 211. In an advantageous embodiment, the flows to be terminated areselected by taking into account properties of flows, e.g., lifetime,data rate, QoS requirements, etc.

Since core nodes do not store per flow information, therefore they donot know that the marked packets at the end of a measurement periodbelong to different flows than the ones marked in the previous period.If core nodes marked the same flows as previously, it would result inthat less flows are terminated than necessary. However, the egress nodehas per flow information, and so remembers which flows were terminatedin the previous measurement period. If marked, packets arrive for a flowterminated in the previous measurement period, termination will bedecided for other flows, if the egress node knows which other flows itcan choose from; that is, if the egress node knows which other flowspassed the congested link.

The egress node can obtain the information of which flows passed thecongested, node from the routing protocol but the hop-by-hop routingscheme of today's networks aims right at distributed knowledge. In orderto provide a mechanism, to identify the flows traversing through thecongested node without relying on external protocols an enhanced, atleast 3-state stamping procedure of the interior node can be usedinstead of the original 2-state stamping.

Packets that are carrying encoded overload information are called‘marked’ packets. In an advantageous embodiment packets that, passed acongested link but are not marked are also stamped with a flag:‘congested but not marked’. Trivially, the 3rd state is if the packet is‘not marked’. The stamping can be done with the help of two bits in thepacket header, e.g., the Explicit Congestion Notification (ECN) bits(described in RFC 2431), or by separating two bits from the DSCF.Another solution is if the network operator locally assigns for everytraffic class two other DSCPs, which are interpreted at its egress nodesas marked or congested but not marked stamps. In this way, the egressnode knows that those packets traversed the congested link that werestamped either with ‘congested but not marked’ or with ‘marked’. Theegress node should select the appropriate number of flows to terminate,as described above, from those flows that received either ‘marked’ or‘congested but not marked’ packets.

A preferred embodiment ensures that multiple simultaneous congestions onseveral links can foe distinguished. To ensure the proper and efficienthandling of congestions the stamping procedure is extended with somekind, of an identifier of the congested link. Each packet, ‘marked’ or‘congested but not marked’, is stamped with an identification code thatis unique for that particular congestion. Such unique identificationcode could foe the node identifiers (IDs) of nodes connected by thecongested link or a random value (large enough to retain uniqueness)derived, independently from other nodes.

Another preferred embodiment ensures that in case of variable traffic,the variability will not trigger multiple congestions in the core node.For example, the bandwidth variation of the Variable Bit Rate (VBR)traffic is around 10% of the link capacity. This means that if, aftercongestion, precisely the maximum possible amount of flows remains, thenthe variable traffic after some time would again exceed the congestiondetection threshold. Therefore, hysteresis should be applied for theoverload detection threshold. Our hysteresis algorithm has two bounds. Ahigher bound is used to detect congestion and to trigger the appropriatecounter-reaction. This reaction consists of marking data packets inproportion to the measured overload. However, a lower bound is used asthe reference to measure the overload ratio. This way, in an ideal case,the congestion reaction terminates the amount of flows so that onlylower bound amount of traffic remains. If the traffic variability issmaller than the difference of the higher and the lower bound, then itwill not trigger congestion again.

In FIG. 3 an embodiment of a core node, e.g., 104 in FIG. 1, handlingsimple resource management information is illustrated. Incominginterfaces 304, 305, 306 are connected to links 301, 302, 303 one ofwhich can foe identical for example to link 109 in FIG. 1. A routingmodule 30 is attached to the incoming interfaces 304, 305, 306, to arouting table 308 and to queues 310, 311, 312. A measurement module 309communicates the queues 310, 311, 312 and a module of congestionhandling 313 containing a storage means 314. The queues 310, 311, 312are further connected to outgoing interfaces 316, 317, 318 and a markermodule 315, receiving information from the module of congestion handling313. The outgoing interfaces 316, 317, 318 forward packets to outgoinglinks 319, 320, 321, one of which can be identical to link 111 in FIG.1.

Up to the route selection, the node is just a simple router. The firstaddition is the measurement module 309, which is used to detect andmeasure overload. In periodical intervals it communicates the measuredoverload for each link 301, 302, 303 to the module of congestionhandling 313. Kith the previously explained, procedure, the module ofcongestion handling 313 determines the amount of overload to signal inthe current period and communicates this to the marker module 315. Themarker module 315 marks packets accordingly and applies advantageouslythe hysteresis algorithm described before, and at the end of the periodtells the module of congestion handling 313 the amount of signalledoverload by a 3-state stamping procedure that encodes overloadinformation and identifies the flows that passed a congested link butare not carrying encoded overload information. As described previously,with the help of this information and the measured overload in the newperiod, the module of congestion handling 313 determines how much of theoverload should be signalled next.

E.g., let us denote the extent of overload during the measuring periodby C_(OL), and the extent of overload identified previously by C_(MEM).C_(MEM) is stored in the storage means 314. If C_(MEM) is stored in asliding window, then at the end of the i^(th) measurement period C_(MEM)is equal to A_(i) (see FIG. 6). The extent of overload for the nextperiod to be identified is equal to the difference of C_(OL) andC_(MEM), which can be denoted by C. If this difference is less thanzero, then nothing should be done. If it is a positive number, then letC_(M) represent the thus far signalled overload in the current, period.Marking of packets shall be continued until the measure of C_(M) exceedsC. Further on marking should be stopped and C_(M) is stored in thestorage means 314.

In FIG. 4, a flow chart of the operation, of a possible egress nodeaccording to the invention is described. According to step 401 a counteris incremented with the decoded overload value of received markedpackets. As it is described above, C_(M) represents the measure of theoverload. In step 402 packets ‘congested but not marked’ are identifiedand flows containing packets marked or ‘congested but not marked’ areidentified as affected flows. Assume, that an affected flow is denotedby f_(i), and a set of such flows can be denoted by S. A new affectedflow f_(i) is added to set S if it has not been element of S previouslyand f_(i) receives a ‘marked’ or ‘congested but not marked’ packet. Thecondition of step 403 is decided if a period of observation is over. Ifthe period is not over, steps 401 and 402 are repeated. In step 404C_(M) is decided to exceed zero or not. If not, then nothing should bedone 405. If C_(M) is greater than zero, then in step 406 some affectedflows are identified so that these flows should generate togethertraffic equal to C_(m). Let in denote the traffic generated by flow i,and let T denote the set of identified flows. It is obvious that set Tis part of set S. If b denotes the sum of b_(i), i.e., traffic generatedby the identified flows, then h should approximate to C_(M), and thecurrent value of C_(M) is set to the amount of C_(M) counted, previouslyminus b. In step 407 congestion report messages are sent for allidentified affected flows to foe terminated. Finally, according to step408, flows to be terminated are removed from set S.

Steps described above can be implemented by processing means in an edgenode. E.g., an egress node having means for decoding the overload frommarked packets; identifying packets that are carrying encoded overloadinformation and packets that passed a congested link not carryingencoded, overload information; adding new flows to the set of affectedflows; identifying affected flows so that, their aggregated load isequal to the overload value derived from the marked packets; sendingmessages for a set of identified affected flows to be terminated; andremoving flows to be terminated from the set of affected flows. In thecase when some or all the steps described above are implemented in aningress node means for signalling the necessary information from egressnodes is also required.

In FIG. 5, a graph of network simulation is shown, illustrating theoverload of the link capacity (vertical axis) in the function of time(horizontal axis) after a congestion event 505. The first curve 501relates to the case where no congestion handling is applied. As it isseen, the link overload remains high in time until it returns to the CACthreshold 504. The second curve 502 snows the effect of a congestionhandling according to the prior art. After the congestion the algorithmover-reacts the event and an ‘undershoot’ can be seen. The third curve503 illustrates the usage of the invention. In this case the linkoverload returns to the normal level, after the congestion without heavyundershoot.

FIG. 6 shows an advantageous embodiment of the storage means 314 withthe help of a method of sliding window. The t_(cell) long measurementperiods are gathered, into a t_(wind) long sliding window so that thet_(wind)=(k t_(cell)), and where t_(wind) is in the order of the roundtrip times as explained above. In the implementation we always have tostore the sum of the signalled overload in the last k measurementperiods so that at the end of timeslot i the sliding window contains(a_(i-k+1), . . . , a_(i-1), a_(i)), and where the sum of these valuesrepresent the remembered amount of previous markings:

$A_{i} = {\sum\limits_{j = {i - k + 1}}^{i}{a_{i}.}}$

At the end of a measurement period, the sliding window is shifted sothat the value of the oldest cell is overwritten with the newest value.

Although preferred embodiments of the present invention have beenillustrated in the accompanying drawings and described in the foregoingdetailed description, it is understood that the invention is not limitedto the embodiments disclosed, but is capable of numerous rearrangements,modifications, and substitutions without departing from the spirit ofthe invention as set forth and defined by the following claims.

What is claimed is:
 1. A system for handling congestion in a packetswitched network domain comprising nodes, which are linked to each othertransmitting data packets in the network domain, the system comprising:a core nods for measuring overload, to mark data packets where an amountof overload is encoded and signaled with packet markings; and an egressnode for receiving from the core node marked and not marked packets,decode the overload amount, from the marked packets in a countinginterval, identify flows to foe terminated and report to ingress node toreduce the traffic volume, wherein the core node is arranged tocalculate an amount of marked packets by taking in account a previouslysignaled overload amount, where the core node implements an at least3-state stamping procedure to encode the overload amount by markedpackets, congested but not marked packets and not marked packets and toidentify flows that passed a congested link but are not marked, andwhere the core node itself applies three-flags to stamp the data packetswhere one flag indicating “marked packets” is stamped to the datapackets traversing a congested link and marked, another flag indicating“congested but not marked packets” is stamped to the data packetstraversing a congested link but not marked and a third flag indicating“not marked packets” is stamped to the data packets traversing notcongested links.
 2. The system of claim 1, wherein the packet switchednetwork domain is an Internet Protocol (IP) domain.
 3. The system ofclaim 1, wherein the core node is arranged to apply a hysteresisalgorithm with a higher hound used to detect congestion and to triggerthe marking of data packets in proportion to the measured overloadamount, and a lower bound used as the reference to measure an overloadratio.
 4. A core node for handling congestion in a packet switchednetwork domain, the core node, comprising: at least one incominginterface connected to at least one link that receives data packets; aprocessor; and a memory that stores processor-executable instructionsthe processor-executable instructions to implement: a measurement modulethat detects and measures overload of the data packets received at theat least one incoming interface; a marker module that marks at least aportion of the received data packets where an amount of overload isencoded and signaled with packet markings, wherein the marker module isarranged to implement an at least 3-state stamping procedure to encodethe overload amount by marked, packets, congested but not marked packetsand not marked packets and to identify flows that passed the at leastone link and are affected by the congestion but are not marked; and themarker module itself applies three-flags to stamp the data packets whereone flag indicating “marked packets” is stamped to the data packetstraversing a congested link and marked, another flag indicating“congested, but not marked packets” is stamped to the data packetstraversing a congested link but not marked and a third flag indicating“not marked packets” is stamped to the data packets traversing notcongested links; and at least one outgoing interface for sending markedand not marked packets.
 5. The core node of claim 4, wherein the atleast 3-stats stamping procedure involves stamps corresponding topackets that are carrying the encoded overload amount and packets thatpassed the at least one congested link but are not carrying encodedoverload amount.
 6. The core node of claim 4, wherein the packetmarkings comprises an identification code of the core node todistinguish among different parallel congestions.
 7. The core node ofclaim 4, wherein the packet markings comprises a random value todistinguish among different parallel congestions.
 8. The core node ofclaim 4, wherein the packet switched network domain is an InternetProtocol domain and the marker module is arranged to implement the atleast 3-state stamping procedure by the Explicit Congestion Notification(BON) bits of the IP packet header.
 9. The core node of claim 4f whereinthe packet switched network domain is an Internet Protocol domain andthe marker module is arranged to separate at least two bits from theDiffServ Code Point (DSCP) for the at least 3-state stamping procedure.10. The core node of claim 4, wherein the packet switched network domainis an Internet Protocol domain and the marker module is arranged toimplement the at least 3-state stamping procedure by a network operatorlocally assigning at least two other DSCPs for each traffic class. 11.The core node of claim 4, wherein a storage means is arranged to storethe previously signaled amount of overload by sliding window.
 12. Thecore node of claim 4t wherein the marker module is arranged to apply ahysteresis algorithm with a higher bound used to detect, congestion andto trigger the marking of data packets in proportion to the measuredoverload amount, and a lower bound used as the reference to measure anoverload ratio.
 13. A method implemented, by a system for congestionhandling in a packet switched network domain comprising nodes, which arelinked to each other transmitting data packets in the network domain,the method comprising the steps of: measuring, in a core node, overloadand marking data packets where an amount of overload is encoded andsignaled with packet markings; calculating, in the core node, an amountof marked packets by taking in account a previously signaled overloadamount; implementing in the core node an at least 3-state stampingprocedure to encode the overload amount by marked packets, congested butnot marked packets and not marked packets and to identify flows thatpassed a congested link but axe not marked, where the core node itselfapplies three-flags to stamp the data packets where one flag indicating“marked packets” is stamped to the data packets traversing a congestedlink and marked, another flag indicating “congested but not markedpackets” is stamped to the data packets traversing a congested link butnot marked and a third flag indicating “not marked packets” is stampedto the data packets traversing not congested links; receiving from thecore node marked and not, marked packets in an egress node; decoding inthe egress node the overload amount from the marked packets in acounting interval; identifying flows to be terminated in the egressnode; and sending congestion report messages from the egress node toingress nodes; terminating the identified flows in at least one ingressnode.
 14. The method of claim 13, further comprising a step of storingthe previously signaled amount of overload by sliding windows.
 15. Themethod of claim 13, wherein the step of identifying the flows to foeterminated is carried out by selecting flows different from the flowsterminated before.
 16. The method of claim 13, wherein the step ofterminating flows in at least one ingress node further comprises theflows to be terminated are randomly selected among the flows that pass acongested node.
 17. The method of claim 13, wherein the step of markingdata packets to encode and signal the amount of overload, applies ahysteresis algorithm with a higher bound used to detect congestion andto trigger marking data packets in proportion to the measured overloadamount, and a lower bound used as the reference to measure an overload,ratio.
 18. A method implemented by a core node for handling congestionin a packet switched network domain, the method comprising the steps of:receiving, at the core node, data packets on at least one; link;detecting and measuring, at the core node, overload of the received datapackets; marking, at the core node, at least a portion of the receiveddata packets where an amount of overload is encoded and signaled withpacket markings, wherein the marking step includes implementing an atleast 3-state stamping procedure to encode the overload amount by markedpackets, congested, but not marked packets and not marked packets and toidentify flows that passed the at least one link and are affected by thecongestion but are not marked; and applying, at the core node,three-flags to stamp the data packets where one flag indicating “markedpackets” is stamped to the data packets traversing a congested link andmarked, another flag indicating “congested but not marked packets” isstamped to the data packets traversing a congested link but not markedand a third flag indicating “nor marked packets” is stamped to the datapackets traversing not congested links; and sending, from the core node,marked and not marked packets.